Metadata Database Lookup System 



BACKGROUND OF THE INVENTION 

5 

TECHNICAL FIELD 

The invention relates to network resource addressing and access. More particularly, the 
10 invention relates to the mapping of network resources using resource ID to universal 
resource locator address mapping. 

DESCRIPTION OF THE PRIOR ART 

15 

Distributed computing systems began with dumb terminals and teletypes connected to 
a central computer. Any resources that the central computer offered were directly 
connected or contained in the central computer itself . As computing systems expanded 
to networked systems, the number of servers that could be accessed by users 
20 increased to whatever servers that could be addressed within the local network itself. 

The Internet resulted in a massively distributed system where many servers and clients 
transferred data among themselves. Service providers now commonly provide 
resource access to users across intranet and Internet systems. To access a resource, a 
25 user must have knowledge of the service provider's location address and the resources 
that are provided by the service provider. 

Uniform Resource Identifiers (URI) and Universal Resource Locators (URL) are short 
strings that identify resources in the Internet (or Web). Examples of resources are: 
30 documents, images, downloadable files, services, electronic mailboxes, etc. The URIs 
and URLs make resources available under a variety of naming schemes and access 
methods such as HTTP, FTP, and Internet mail uniformly addressable. 

A user accesses the desired resource using the URI of the resource. The drawback to 
35 this approach is that the user must have knowledge of the particular resource and the 
URL address of the service provider. 
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It would be advantageous to provide a metadata database lookup system that 
provides a requesting system with an identifier for a service provider that is used to 
reference a URL address for a resource provided by the service provider. It would 
further be advantageous to provide a metadata database lookup system that provides 
5 a database reference method that can be implemented in a centralized enterprise 
system as well as an Internet configuration. 



SUMMARY OF THE INVENTION 

10 

The invention provides a metadata database lookup system. The invention provides a 
requester with an identifier for a service provider that is used to reference a URL address 
for a resource provided by the service provider. In addition, the invention provides a 
database reference method that is easily implemented in a centralized enterprise 
1 5 system as well as an Internet configuration. 

A preferred embodiment of the invention provides a database is that contains a cross- 
reference of metadata information to a service provider ID number or universal resource 
identifier (URI). A service provider ID number is keyed to information about a specific 
20 resource from a service provider. The metadata information can contain a description of 
the resource, the universal resource locator (URL) for the resource, and any other 
pertinent information that may be associated with the resource. The invention uses a 
constant ID number for a service provider and its resource. 

25 A resource requestor uses the ID number for requesting metadata information for the 
desired service provider resource. The ID number is cross referenced with the proper 
information for the resource and the resource is then addressed by the resource 
requestor using the URL. The resource requestor uses the metadata information as 
needed and accesses the resource using the URL in the metadata information. The 

30 resource requester is unaffected by updates to a resource's description or address by 
the service provider. 

In an embodiment of the invention, the database is stored on a central storage server. 
The database contains resource metadata information for all of the service providers 
35 within the central storage server's responsibility. The central storage server's 
responsibility can be locality, assignment, or trust based. When a resource requestor 
needs to access a resource, the resource requestor sends a metadata information 
request with the service provider's ID to the central storage server. 
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The central storage server verifies the request, references its database using the service 
provider's ID, and retrieves the service provider's resource information from the 
database. The central storage server sends the resource information to the resource 
requestor. 

5 

The resource requestor uses the resource metadata information to, for example, display 
the resource description to a user. When the resource requestor needs to access the 
resource, it uses the URL obtained from the resource metadata information to access the 
resource from the service provider. The service provider resource returns the 
1 0 appropriate data to the resource requestor. 

In another embodiment of the invention, the database resides locally on a service 
provider's site. The database contains resource information for the service provider's 
resources. When a resource requestor needs to access one of the service provider's 
1 5 resources, the resource requestor sends a metadata information request with the service 
provider's ID to the service provider. 

The service provider receives the information request from the resource requestor and 
references its local database using the ID. The ID is cross referenced to the information 
20 for the service provider's resource. The resource information is then sent from the 
service provider to the resource requestor. 

The resource requestor uses the resource information to, for example, display the 
resource description to a user. When the resource requestor needs to access the 
25 resource, it uses the URL obtained from the resource information to access the resource 
from the service provider. The service provider's resource returns the appropriate data 
to the resource requestor. 

Other aspects and advantages of the invention will become apparent from the following 
30 detailed description in combination with the accompanying drawings, illustrating, by way 
of example, the principles of the invention. 



BRIEF DESCRIPTION OF THE DRAWINGS 

35 

Fig. 1 is a block schematic diagram of a network view of the invention according to the 
invention; 
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Fig. 2 is a diagram of an exemplary database entry showing cross referencing of a URI 
to a resource URL according to the invention; 

Fig. 3 is a block schematic diagram illustrating a centralized approach of the invention 
5 where a resource database is located in a centralized server according to the invention; 

Fig. 4 is a block schematic diagram illustrating a localized approach of the invention where 
resource databases are located at a service provider's site according to the invention; 
and 

10 

Fig. 5 is a block schematic diagram of an task viewpoint of the invention according to the 
invention. 

DETAILED DESCRIPTION OF THE INVENTION 

15 

The invention is embodied in a metadata database lookup system. A system 
according to the invention provides a requester with an identifier for a service provider 
that is used to reference a URL address for a resource provided by the service 
provider. The invention additionally provides a database reference method that is 
20 easily implemented in a centralized enterprise system as well as an Internet 
configuration. 

Resources such as documents, images, downloadable files, services, electronic 
mailboxes, etc., are typically provided across networks by individual companies to 

25 other companies and users. These resources must somehow be maintained by the 
providing company, or service provider, during the normal course of business. For 
example, the maintenance of resources can include relocating the resource to another 
address where the address is a universal resource locator (URL) because a server was 
overloaded, updating a text description of a resource due to an expansion or contraction 

30 of services, etc. 

A drawback to updates is that other service providers and users (resource requestors) 
may not be aware of the updates and somehow must be notified. Without any 
notification, resource requestors will encounter errors such as broken links or unexpected 
35 results from the resource. The service provider must somehow update information 
about its resource across multiple locations across the attached network whenever a 
change is effected. This becomes a large problem that makes it difficult for the service 
provider to maintain its resources. 
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The invention provides a simpler, more efficient approach that allows a resource 
requestor to use an ID that does not change to access a resource. Using an ID allows 
the resource requestor to quickly access the resource. The ID is resolved by a central 
server or service provider to the resource's actual address and description and provided 
5 to the resource requestor. The resource requestor then uses the address to access the 
resource. 

The invention allows service providers to change information regarding their resources 
by updating resource information at a location that is under their control. The invention 
1 0 makes it much easier and convenient for service providers to maintain their resources. 

Referring to Fig. 1, service providers 102, 103, 104, 105 provide resources across a 
network 101, such as the Internet. The resources are available to clients 102, 106 and 
other service providers 102, 103, 104, 105. Traditional systems require that the clients 
15 102, 106 and other service providers 102, 103, 104, 105 know the specific Universal 
Resource Locator (URL) of the service provider's resource to access the resource. 

A preferred embodiment of the invention allows clients 102, 106 and other service 
providers 102, 103, 104, 105 to use a service provider's ID number to obtain an 

20 address to a service provider's resource. The service provider's ID number can be a 
Uniform Resource Identifier (URI) or a predetermined numerical ID. The ID number is 
keyed to a specific resource for the service provider. A database is provided that cross 
references ID numbers with resource URLs. The invention assures that the service 
provider does not have to update multiple locations whenever a resource description or 

25 location is changed. 

Typically, resource requestors had to update their links to service provider's resources 
whenever a resource changed at the service provider's site. This caused dead links and 
other access problems. The invention solves these problems by using a constant ID 
30 number for the service provider and its resource. A resource requestor uses the ID 
number for the desired service provider resource. The ID number is cross referenced 
with the proper URL for the resource and the resource is then addressed by the 
resource requestor using the URL. The resource requester is unaffected whenever a 
service provider updates a resource's description or address. 

35 

In another preferred embodiment of the invention, the service provider ID number is 
keyed to a location in the database that contains metadata relating to the service 
provider's resource. The metadata can contain a description of the resource, the URL for 
the resource, and any other pertinent information that may be associated with the 
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resource. When the resource requester sends a request to the ID number, the 
metadata for the particular resource is returned to the resource requestor. The resource 
requestor uses the metadata as needed and accesses the resource using the URL in 
the metadata. 

5 

With respect to Fig. 2, a database 201 is provided that contains a cross-reference of 
metadata information 205 to a URI 202. A URI 202 is keyed to information about a 
specific resource from a service provider. Depending on the application (as described 
below), the database tracks the metadata and URIs for resources for a specific sen/ice 
1 0 provider or resources for multiple service providers. 

Metadata 205 are composed of data concerning a resource. For example, a resource 
URL 203 tells the resource requestor the address where the resource is located, a 
description of the resource 204 is included as well as other pertinent information 206. 

15 

The database can be located in a central server in an enterprise situation or distributed 
within service providers. The invention changes the URI to a URL. The URL is now 
both the URI and the resource locator. 

20 Referring to Fig. 3, a centralized approach of a preferred embodiment of the invention is 
shown where the database is stored on a central storage server 302. The database 
contains resource information for all of the service providers within the central storage 
server's responsibility. The central storage server's area of responsibility can be locality, 
assignment, or trust based. When a resource requestor 301 needs to access a 

25 resource, the resource requestor 301 sends a metadata information request with the 
service provider's ID 304 to the central storage server 302. 

The central storage server 302 verifies the request and references its cross reference 
database using the service provider's ID (URI in this case). The URI key is found in the 
30 database and the service provider's resource information is retrieved from the database. 
The resource information is sent from the central storage server 302 to the resource 
requestor 301 . 

The resource requestor 301 uses the resource information to, for example, display the 
35 resource description to a user. When the resource requestor 301 needs to access the 
resource, it uses the URL from the resource information to access the resource from the 
service provider 303. The URL addresses the service provider 303 resource. The 
service provider 303 resource returns the appropriate data 307 to the resource 
requestor 301. 



With respect to Fig. 4, a distributed network approach of a preferred embodiment of the 
invention is shown where the database resides locally on the service provider 402 site. 
The database contains resource information for the service provider's resources. When 
a resource requestor 401 needs to access one of the service provider's resources, the 
5 resource requestor 401 sends a metadata information request with the service 
provider's ID 403 to the service provider 402. 

The service provider 402 receives the information request from the resource requestor 
401 and references its local database using the ID. The ID is cross referenced to the 
1 0 information for the service provider's resource. The service provider 402 retrieves the 
information for the requested resource from the cross referenced location. The resource 
information is then sent 404 from the service provider 402 to the resource requestor 
401. 

15 The resource requestor 401 uses the resource information to, for example, display the 
resource description to a user. When the resource requestor 401 needs to access the 
resource, it uses the URL from the resource information to access the resource 405 from 
the service provider 402. The URL addresses the service provider resource. The 
sen/ice provider's 402 resource returns the appropriate data 406 to the resource 

20 requestor 401. 

Referring to Fig. 5, a task viewpoint of the invention is shown. The resource database 
505 is created by the create resource DB task 504. The create resource DB task 504 
creates a resource database 505 that is dependent upon the application. If the resource 
25 database 505 is targeted for a central storage server, the create resource DB task 504 
creates a resource database 505 that contains the resource information for all of the 
service provider resources in the central storage server's area of responsibility. This 
could cover multiple service providers and their resources. 

30 For the case where a service provider hosts the resource database 505 locally on its 
site, the create resource DB task 504 creates a resource database 505 that contains the 
resource information for all of the service provider's resources. 

During normal operation, a receive information request task 501 receives metadata 
35 information requests from resource requestors. The receive information request task 501 
passes the service provider ID to the perform DB lookup task 502. The perform DB 
lookup task 502 looks into the resource database 505 and cross references the service 
provider ID to find the corresponding resource information. The perform DB lookup task 
502 passes the resource information to the send resource data task 503. 
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The send resource data task 503 previously receives the resource requestor's address 
from the receive request task 501 . Once the send resource data task 503 receives the 
resource information from the perform DB lookup task 502, it sends the resource 
information to the resource requestor's address. 

5 

The problem is that there is a resource and a resource ID and it is difficult to access to 
resource quickly using the ID. The user tries to get the resource by the name. In our 
case, the resource ID is a Universal Resource Identifier (URI). This happens over a 
network with different computers referencing the resource and needing to quickly get to 
1 0 the resource through the resource ID. 

The following is an example of an application of the invention in a trusted environment 
where the resource requestors and service providers are trusted entities among 
themselves. 

15 

Trusted Environment Example 
Centralized "metadata service". 

20 The centralized "metadata service" provides a metadata exchange service for all service 
providers inside a circle of trust. Any service provider may request metadata for another 
sen/ice provider from the metadata service or upload its own metadata information to 
the "metadata service". The metadata sen/ice supports the 

<metadata:MetaDataGetRequest> request and may also support 

25 <metadata:MetaDataPostRequest> request. 

To improve performance, the service provider may cache the metadata information 
retrieved from metadata service according to cache control directive in the response. 

30 Distributed metadata storage. 

Every service or identity provider has a URI based provider ID that uniquely identifies 
the provider in the network. In case of distributed metadata storage, the provider ID 
URI is interpreted as a URL that points to the provider's metadata (for example, a 
35 service provider's SOAP endpoint URL may be used as a provider's ID URI). When 
a service provider wants to get data for another provider it simply issues 
<metadata:MetaDataGetRequest> request to the provider ID URL and receives in a 
response, the provider's metadata in the <metadata:MetaDataGetResponse> 
response. In most cases, in response to the <metadata:MetaDataGetRequest> 
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request, the service provider returns the same metadata information. However, the 
service provider may return different metadata information depending on the requestor's 
provider ID 

5 To improve performance, the service provider may cache the metadata information 
retrieved from another service provider according to a cache control directive in the 
response. 

Security 

10 

To prevent metadata "spoofing" the receiver of metadata information should verify its 
integrity and origin using XML Signature, SSL/TLS authentication or any other secure 
equivalent method. Most of the metadata information is not sensitive and by this does 
not require encryption. However, transport level encryption (SSL/TLS), message level 
15 encryption (XML Encryption) or any other secure equivalent method may be used to 
protect the metadata information. Also "metadata service" or service provider MAY 
restrict the metadata distribution (using the requestor's provider ID). 

<MetaDataGetRequest> request 

20 

The service provider issues <metadata:MetaDataGetRequest> request to a metadata 
service or another service provider's provider ID URL in order to obtain the metadata 
information. 

25 Schema definition. 

The elements of the request are as follows: 

MajorVersion [Required] 
30 Major version of the request. 

MinorVersion [Required] 

Minor version of the request. 
ProviderlD [Required] 

The requestor service provider's URI-based identifier. 
35 SubjectProviderlD [Required] 

The URI-based identifier that identifies service provider to retrieve metadata for. 
IfModifiedSince [Optional] 

The time of the current metadata information available to the requestor. 
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Signature [Optional] 

The request signature. 

The schema fragment defining the element and its type is as follows: 

5 

<element name^'MetaDataGetRequest" type="metadata:GetRequestType7> 
<complexType name="GetRequestType"> 
<sequence> 

<element name="ProviderlD" type= H anyURI7> 
1 0 <element name="SubjectProviderlD" type= M anyURI7> 

<element name="lfModifiedSince" type= M dateTime" minOccurs="07> 
<element ref="ds:Signature" minOccurs="07> 
</sequence> 

<attribute name="MajorVersion" type="integer" use="required7> 
1 5 <attribute name= M MinorVersion ,, type="integer n use="required7> 

</complexType> 

Example: 

<MetaDataGetRequest MajorVersion="1" MinorVersion="0"> 

<ProviderlD>http://ServiceProvider1.com/id</ProviderlD> 
<SubjectProviderlD>http://ServiceProvider2.com/id</SubjectProviderlD> 
<lf Modif iedSince>2002-1 2-1 7T09:30:47-05:00</lfModif iedSince> 
<ds:Signature>...</ds:Signature> 
</MetaDataGetRequest> 

Processing Rules 

When a metadata service or service provider receives an 
30 <metadata:MetaDataGetRequest> request, it processes the request according to the 
following rules: 

• <ds:Signature>, if present, it is the signature of the service provider. 

• The service provider should respond with NotModified status code if the 
35 <metadata: If Modif iedSince> element is present and the metadata has not been 

modified since the time specified in this element. 

<MetaDataGetResponse> response 
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The <metadata:MetaDataGetResponse> response contains a provider's metadata 
information along with a process control directive for requestor. 

Schema definition. 

The elements of the response are as follows: 

MajorVersion [Required] 

Major version of the response. 
MinorVersion [Required] 

Minor version of the response. 
Status [Required] 

A status of the request. 
Issuelnstant [Required] 

The time instant of issue the response. 
CacheControl [Optional] 

The cache control directives. 
Descriptor [Optional] 

The service provider metadata. 
Signature [Optional] 

The response signature. 

The schema fragment defining the element and its type is as follows: 

<element name="MetaDataGetResponse" type="metadata:GetResponseType7> 
<complexType name="GetResponseType"> 
<sequence> 

<element ref= ,, libmetadata:Status7> 

<element name="lssuelnstant H type= M dateTime7> 

<element name="Descriptor" type="lib:ProviderDescriptorType" 

minOccurs= n 07> 
<element ref= M metadata:CacheContror minOccurs= H 07> 
<element ref= ,, ds:Signature" minOccurs="07> 
</sequence> 

<attribute name= ,, MajorVersion" type="integer" use="required7> 
<attribute name= ,, MinorVersion" type="integer" use="required7> 
</complexType> 

Element <Status>. 

1 1 



The <metadata:Status> element: 

StatusCode [Required] 
5 The code representing status of corresponding request. 

StatusMessage [Any Number] 

A message, which may be returned to an operator. 
StatusDetail [Optional] 

Additional information about the error condition. 

The schema fragment defining the element and its type is as follows: 

<element name="Status" type="metadata:StatusType7> 
<complexType name="StatusType ,, > 
<sequence> 

<element ref="metadata:StatusCode7> 

<element ref="metadata:StatusMessage ,, minOccurs="0" 

maxOccurs="unbounded7> 
<element ref="metadata:StatusDetair' minOccurs="07> 
</sequence> 
</complexType> 

<element name="StatusMessage" type="string7> 
<element name= n StatusDetail" type="metadata:StatusDetailType7> 
<complexType name="StatusDetailType"> 
<sequence> 

<any namespace="##any" processContents="lax" minOccurs="0 n 

maxOccurs="unbounded7> 

</sequence> 
</complexType> 

Element <StatusCode>. 

The <metadata:StatusCode> element specifies a code representing the status of 
corresponding request: 
35 

Value [Required] 

The status code as defined below. 
SubStatusCode [Optional] 
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An optional subordinate status code that provides more specific information 
about the error condition. 



The following StatusCode values are defined: 

5 

Success 

The request succeeded. 
NotModified 

The metadata has not been modified since the time specified by the sender. 
1 0 VersionMismatch 

Receiver could not process the request because of version mismatch. 
Receiver 

The request could not be performed due to an error at the receiving end. 
Sender 

15 The request could not be performed due to an error in the sender or in the 

request. 

The schema fragment defining the element and its type is as follows: 

20 <element name="StatusCode" type= ,, metadata:StatusCodeType7> 

<complexType name="StatusCodeType"> 
<sequence> 

<element name="SubStatusCode" type="integer" minOccurs="07> 
</sequence> 

25 ettribute name="Value" type="metadata:StatusCodeEnumType" use="required7> 

</complexType> 

<simpleType name= ,, StatusCodeEnumType"> 
restriction base="QName"> 

enumeration value="Success7> 
30 enumeration value="NotModified7> 

enumeration value="VersionMismatch7> 
enumeration value="Reciever7> 
enumeration value="Sender7> 
</restriction> 
35 </simpleType> 

Element <CacheControl>. 

The <metadata:CacheControl> element: 
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MinAge [Optional] 

The minimum caching time (in seconds). 
MaxAge [Optional] 

The maximum caching time (in seconds). 

The schema fragment defining the element and its type is as follows: 

<element name="CacheControl" type="metadata:CacheControlType7> 

<complexType name="CacheControlType"> 

<attribute name="MinAge u type="integer n use="optional7> 
<attribute name="MaxAge" type= ,, integer" use= ,, optional7> 

</complexType> 

Example: 

<MetaDataGetResponse MajorVersion="1" MinorVersion= n O"> 
<Status> 

<StatusCode Value="Success7> 
</Status> 

<lssuelnstant>2002-1 2-1 7T09:30:47-05:00</lssuelnstant> 
<Descriptor> 

<ProviderlD>http://ServiceProvider.com</ProviderID> 

<ProviderSuccinctlD>A9FD64E12C</ProviderSuccinctlD> 

<ds:Keylnfo>...</ds:Keylnfo> 

<SoapEndpoint>http://ServiceProvider.com/soap</SoapEndpoint> 

<SingleLogoutSeraceURL>http://ServiceProvider.com/slo</SingleLogoutSeiviceURL> 

<SingleLogoutServiceReturnURL>http://ServiceProviderxom/slo_return</SingleLogoutSe 
rviceReturnURL> 

<FederationTerminationSe™iceURL>^ 
onServiceURL> 

<FederationTerminationServiceReturnURL^^ 
ationTerminationServiceReturnURL> 
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<AssertionConsumerSeiviceURL>http://^^ 
onConsumerServiceURL> 

<FederationTerminationNotificationProto^ 
ederationTerminationNotificationProtocolProfile> 

<SingleLogoutProtocolProfile>http://test.org/profiles/slo_soap</SingleLogoutProtocolProfil 

e> 

<AuthnRequestsSigned>1</AuthnRequestsSigned> 
</Descriptor> 

<CacheControl MinAge="3600" MaxAge="360007> 
<ds:Signature>...</ds:Signature> 
</MetaDataQetResponse> 

Processing rules 

When a service provider receives an <metadata:MetaDataGetResponse> from 
another service provider, it processes the request according to the following rules: 

• <ds:Signature>, if present, is a valid signature of the service provider. 

• If the value of <metadata:StatusCode> element is NotModified then the current 
version of the service provider's metadata should be used. 

• The service provider caches the returned metadata and uses the timestamp 
returned in the <metadata:lssuelnstant> element as the value of the 
<metadata:lfModifiedSince> element in next metadata request. 

• If the <metadata:CacheControl> element is present then service provider should 
not request the metadata again in next minAge seconds and should update the 
cached metadata after maxAge seconds. 

<MetaDataPostRequest> request 

The service provider issues <metadata:MetaDataPostRequest> request to a metadata 
service to upload the metadata information. 

Schema definition 

The elements of the request are as follows: 
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MajorVersion [Required] 

Major version of the request. 
MinorVersion [Required] 

Minor version of the response. 
5 ProviderlD [Required] 

The requestor service provider's URI-based identifier. 
Descriptor [Required] 

The service provider metadata. 
CacheControl [Optional] 
1 0 The cache control directives to be used. 

Signature [Optional] 

The request signature. 

The schema fragment defining the element and its type is as follows: 

<element name="MetaDataPostRequest" type="metadata:PostRequestType7> 
<complexType name="PostRequestType"> 
<sequence> 

<element name= , 'ProviderlD" type="anyURI7> 
<element name="Descriptor" type="ProviderDescriptorType"/> 
<element ref="metadata:CacheContror minOccurs="07> 
<element ref="ds:Signature" minOccurs=''07> 
</sequence> 

<attribute name="MajorVersion" type="integer" use="required7> 
<attribute name="MinorVersion" type= M integer" use="required7> 
</complexType> 

Example: 

30 <MetaDataPostRequest MajorVersion="1" MinorVersion="0"> 

<ProviderlD>http://ServiceProvider.com/id</ProviderlD> 
<Descriptor> 

<ProviderlD>http://ServiceProvider.com</ProviderlD> 
<ProviderSuccinctlD>A9FD64E12C</ProviderSuccinctlD> 
35 <ds:Keylnfo>...</ds:Keylnfo> 

<SoapEndpoint>http://ServiceProvider.com/soap</SoapEndpoint> 

<SingleLogoutSei^iceURL>http://ServiceProvider.com/slo</SingleLogoutServiceURL> 
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<SingleLogoutSemceReturnURL>http://ServiceProviderxom/lib/slo_return</SingleLogout 
ServiceReturnURL> 

5 <FederationTerminationSemceURL>http://ServiceProviderxom/lib/term 
ationServiceURL> 

<FederationTerminationServiceReturnURL>^ 
ationTerminationServiceReturnURL> 

10 

<AssertionConsumerServiceURL>http://Servic^ 
onConsumerServiceURL> 

<FederationTerminationNotificationProtocolProfile>http://test.org/profiles/fedterm_so 
1 5 ederationTerminationNotificationProtocolProfile> 

<SingleLogoutProtocolProfile>http://test.org/profiles/slo_soap</SingleLogoutProtocolProfi 

e> 

<AuthnRequestsSigned>1</AuthnRequestsSigned> 
20 </Descriptor> 

<CacheControl MinAge="3600 u MaxAge="360007> 
<ds:Signature>...</ds:Signature> 
</MetaDataPostRequest> 

25 Processing rules 

When a metadata service receives an <metadata:MetaDataPostRequest> from a 
service provider, it processes the request according to the following rules: 

30 • <ds:Signature>, if present, it is the signature of the service provider as specified 
by the <metadata:ProviderlD>. 
• <metadata:CacheControl>, if present, specifies the cache control directives that 
should be used in the <metadata:MetaDataGetResponse> when the metadata 
for this service provider are requested. 

35 

<MetaDataPostResponse> response 

The metadata service issues <metadata:MetaDataPostResponse> response with the 
results of uploading a service provider's metadata. 
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Schema definition 

The elements of the response are as follows: 

5 

MajorVersion [Required] 

Major version of the response. 
MinorVersion [Required] 

Minor version of the response. 
1 0 Status [Required] 

A status of the request. 
Issuelnstant [Required] 

The time instant of issue the response. 
Signature [Optional] 
1 5 The response signature. 

The schema fragment defining the element and its type is as follows: 

<element name^'MetaDataPostResponse" type="metadata:PostResponseType7> 
<complexType name= ,, PostResponseType ,, > 
<sequence> 

<element ref="metadata:Status7> 
<element name="lssuelnstant" type="dateTime7> 
<element ref="ds:Signature" minOccurs="07> 
</sequence> 

<attribute name="MajorVersion" type="integer" use="required7> 
<attribute name="MinorVersion" type="integer" use= n required7> 
</complexType> 

30 Example: 

<MetaDataPostResponse MajorVersion="1 " MinorVersion="0"> 
<Status> 

<StatusCode Value="Success7> 
35 </Status> 

<lssuelnstant>2002-1 2-1 7T09:30:47-05:00</lssuelnstant> 
<ds:Signature>...</ds:Signature> 
</MetaDataGetResponse> 
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Processing rules. 

When a service provider receives an <metadata:MetaDataPostResponse> from a 
metadata service, it processes the request according to the following rules: 

• <ds:Signature>, if present, it is a valid signature of the service provider. 

Although the invention is described herein with reference to the preferred embodiment, 
one skilled in the art will readily appreciate that other applications may be substituted for 
those set forth herein without departing from the spirit and scope of the present 
invention. Accordingly, the invention should only be limited by the Claims included 
below. 
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